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Description 

This invention relates to personal computer sys- 
tems and in particular to means for protecting and stor- 
ing system utilities in a direct access storage device of 
the personal computer system. 

Cross Reference to Related Patent Applications 

The present patent application is one of a group of 
copending applications which concern the same overall 
personal computer system but which individually claim 
different inventive concepts embodied in such personal 
computer system. These related patent applications are 
to be considered as state of the art according to Article 
54(3) EPC, and are more particularly identified as fol- 
lows: 

European Patent Application Number 90307295.7 

published as EP-A-0 419 904 

European Patent Application Number 90307297.3 

published as EP-A-0 417 888 

European Patent Application Number 90307301.3 

published as EP-A-0 417 889 

European Patent Application Number 90307307.0 

published as EP-A-0 41 9 005 

Background Discussion 

Personal computer systems in general and IBM per- 
sonal computers in particular have attained widespread 
use for providing computer power to many segments of 
today's modern society. Personal computer systems 
can usually be defined as a desktop, floor standing, or 
portable microcomputer that consists of a system unit 
having a single system processor, a display monitor, a 
keyboard, one or more diskette drives, a fixed disk stor- 
age, and an optional printer. One of the distinguishing 
characteristics of these systems is the use of a mother- 
board or system planar to electrically connect these 
components together. These systems are designed pri- 
marily to give independent computing power to a single 
user and are inexpensively priced for purchase by indi- 
viduals or small businesses. Examples of such personal 
computer systems are IBM's PERSONAL COMPUTER 
AT and IBM's PERSONAL SYSTEM/2 Models 25, 30, 
50, 50Z, 55SX, 60, 65SX, 70 and 80. 

These systems can be classified into two general 
families. The first family, usually referred to as Family I 
Models, use a bus architecture exemplified by the IBM 
PERSONAL COMPUTER AT and other "IBM compati- 
ble" machines. The second family, referred to as Family 
II Models, use IBM's MicroChannel bus architecture ex- 
emplified by IBM's PERSONAL SYSTEM/2 Models 50 
through 80. 

Beginning with the earliest personal computer sys- 
tem of the family I models, such as the IBM Personal 
Computer, it was recognised that software compatibility 



would be of utmost importance. In order to achieve this 
goal, an insulation layer of system resident code, also 
known as "firmware", was established between the 
hardware and software. This firmware provided an op- 
5 erational interface between a user's application pro- 
gram/operating system and the device to relieve the us- 
er of the concern about the characteristics of hardware 
devices. Eventually, the code developed into a BASIC 
input/output system (BIOS), for allowing new devices to 
70 be added to the system, while insulating the application 
program from the peculiarities of the hardware. The im- 
portance of BIOS was immediately evident because it 
freed a device driver from depending on specific device 
hardware characteristics while providing the device driv- 
es er with an intermediate interface to the device. Since Bl - 
OS was an integral part of the system and controlled the 
movement of data in and out of the system processor, 
it was resident on the system planar and was shipped 
to the user in a read only memory (ROM). For example, 
20 BIOS in the original IBM Personal Computer occupied 
8K of ROM resident on the planar board. 

As new models of the personal computer family 
were introduced, BIOS had to be updated and expanded 
to include new hardware and I/O devices. As could be 
25 expected, BIOS started to increase in memory size. For 
example, with the introduction of the IBM PERSONAL 
COMPUTER AT, BIOS grew to require 32K bytes of 
ROM. 

Today, with the development of new technology, 
30 personal computer systems of the Family II models are 
growing even more sophisticated and are being made 
available to consumers more frequently. Since the tech- 
nology is rapidly changing and new I/O devices are be- 
ing added to the personal computer systems, modifica- 
35 tion to the BIOS has become a significant problem in the 
development cycle of the personal computer system. 

For instance, with the introduction of the IBM Per- 
sonal System/2 with Micro Channel architecture, a sig- 
nificantly new BIOS, known as advanced BIOS, or ABI- 
40 OS, was developed. However, to maintain software 
compatibility, BIOS from the Family I models had to be 
included in the Family II models. The Family I BIOS be- 
came known as Compatibility BIOS or CBIOS. However, 
as previously explained with respect to the IBM PER- 
45 SONAL COMPUTER AT, only 32K bytes of ROM were 
resident on the planar board. Fortunately, the system 
could be expanded to 96K bytes of ROM. Unfortunately, 
because of system constraints, this turned out to be the 
maximum capacity available for BIOS. Luckily, even 
50 with the addition of ABIOS, ABIOS and CBIOS could 
still squeeze into 96K of ROM. However, only a small 
percentage of the 96K ROM area remained available for 
expansion. With the addition of future I/O devices, CBI- 
OS and ABIOS will eventually run out of ROM space. 
55 This, new I/O technology will not be able to be easily 
integrated within CBIOS and ABIOS. 

Due to these problems, plus the desire to make 
modifications in Family II BIOS as late as possible ill the 
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development cycle, it became necessary to offload por- 
tions of BIOS from the ROM. This was accomplished by 
storing portions of BIOS on a mass storage device such 
as a fixed disk. Since a disk provides writing as well as 
reading capabilities, it became feasible to modify the ac- 
tual BIOS code on the disk. The disk, while providing a 
fast and efficient way to store BIOS code, nevertheless 
greatly increased tile probability of the BIOS code being 
corrupted. Since BIOS is an integral part of the operating 
system, a corrupt BIOS could lead to devastating results 
and in many cases to complete failure and non-opera- 
tion of the system. Thus, it became quite apparent that 
a means for preventing unauthorised modification of the 
BIOS code on the fixed disk was highly desirable, this 
was the subject matter of European Patent application 
90307301.3. 

In addition to the storing of BIOS on a mass storage 
device, storing of system utilities normally contained on 
a system reference diskette became highly desirable. 
The elimination of the system diskette not only reduces 
the price of the system, but provides a more userfriendly 
environment. 

It is appropriate at this time to briefly explain the pur- 
pose of the system utilities previously stored on the ref- 
erence diskette. With the introduction of IBM's PS/2 Mi- 
cro Channel Systems came the removal of switches and 
jumpers from I/O adapter cards and planar. Micro Chan- 
nel Architecture provided for programmable registers to 
replace them. Utilities to configure these programmable 
registers or programmable option select (POS) registers 
were required. In addition, other utilities to improve sys- 
tem usability characteristics along with system diagnos- 
tics were shipped with each system on this system ref- 
erence diskette. 

Prior to initial use, each Micro Channel System re- 
quired its POS registers to be initialised. For example, 
if the system is booted with a new I/O card, or a slot 
change for an I/O card, a configuration error is generat- 
ed and the system boot up procedure halts. The user is 
then prompted to load the system reference diskette and 
press the F1 key. A "Set Configuration Utility" can then 
be booted from the system reference diskette to config- 
ure the system. The Set Configuration Utility will prompt 
the user for the desired action. If the appropriate I/O 
card's descriptor files are loaded on the system refer- 
ence diskette ; the Set Configuration Utility will generate 
the correct POS or configuration data in non-volatile 
storage. The descriptor file contains configuration infor- 
mation to interface the card to the system. 

Although this procedure is fairly easy to perform, the 
system reference diskette must be handy or convenient- 
ly stored nearby. It has occurred, after some period of 
time has elapsed, that the system reference diskette has 
become misplaced. Therefore it has become highly de- 
sirable to store a copy of the system reference diskette 
on the mass storage device, along with BIOS, to im- 
prove the usability of the System. 

According to the present invention there is provided 



a personal computer system having a system processor 
for executing an operating system, a read only memory, 
a random access memory, and peripheral devices in- 
cluding at least one direct access storage device the 

5 system having an interface program to control the move- 
ment of data into and out of the processor, characterised 
in that the direct access storage device has a protection 
means for protecting a region of the direct access stor- 
age device in which a portion of the interface program 

70 is stored, the protection means allowing access to the 
protected region in response to a reset signal, the said 
portion of the interface program being operable, when 
loaded into the random access memory, to boot the op- 
erating system and to activate the protection means to 

15 prevent access to the protected region of the direct ac- 
cess storage device during operation of the operating 
system, the protected region of the direct access stor- 
age device further including system utility programs 
which are executed upon detecting an error condition in 

20 the loading of the operating system. 

According to an embodiment of the present inven- 
tion the personal computer system comprises a system 
processor, a random access memory, a read only mem- 
ory, and at least one direct access storage device. A di- 

25 rect access storage device controller may he coupled 
between the system processor and direct access stor- 
age device and include a means for protecting a region 
of the storage device. The protected region of the stor- 
age device may include a master boot record, a BIOS 

30 image and the system reference diskette image. The Bl - 
OS image includes a section known as Power on Self 
Test (POST). POST is used to test and initialise a sys- 
tem. Upon detecting any configuration error, system util- 
ities from the system reference diskette image, such as 

35 set configuration programs, diagnostic programs and 
utility programs can be automatically activated. 

In particular, in response to a reset signal to boot 
up the system, the protection means permits access to 
the protected region to allow the master boot record to 

40 be loaded into random access memory. In operation, the 
master boot record further loads the BIOS image into 
random access memory. BIOS, now in random access 
memory, is executed and boots up the operating system 
to begin operation of the system and BIOS then gener- 
is ates a second signal which activates the protection 
means to prevent access to the region on the disk con- 
taining the master boot record and the BIOS image. If 
BIOS (POST) detects an error, BIOS generates a third 
signal to disable the protection means and then tries to 

50 boot up a system reference diskette found in a bootable 
diskette drive. If there is no system reference diskette 
then BIOS boots up the system utilities in the system 
partition region. 

In particular, the read only memory includes a first 

55 portion of BIOS. The first portion of BIOS initialises the 
system processor, the direct access storage device and 
resets the protection means to read the master boot 
record from the protected region or partition on the direct 
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access storage device into the random access memory. 
The master boot record includes a data segment and an 
executable code segment. The data segment includes 
data representing system hardware and a system con- 
figuration which is supported by the master boot record, s 
The first BIOS portion confirms the master boot record 
is compatible with the system hardware by verifying the 
data from the data segment of the master boot record 
agrees with data included within the first BIOS portion 
representing the system processor, system planar, and 10 
planar I/O configuration. 

If the master boot record is compatible with the sys- 
tem hardware, the first BIOS portion vectors the system 
processor to execute the executable code segment of 
the master boot record. The executable code segment is 
confirms that the system configuration has not changed 
and loads in the remaining BIOS portion from the direct 
access storage device into random access memory. The 
executable code segment then verifies the authenticity 
of the remaining BIOS portion, vectors the system proc- 20 
essor to begin executing the BIOS now in random ac- 
cess memory. BIOS, executing in random access mem- 
ory, generates the second signal for protecting the disk 
partition having the remaining BIOS and then boots up 
the operating system to begin operation of the personal 25 
computer system. The partition holding the remaining 
BIOS is protected to prevent access to the BIOS code 
on disk in order to protect the integrity of the BIOS code. 

However, if either an error or a user initiated diag- 
nostic boot key sequence is detected by BIOS prior to 30 
booting the operating system, the system reference dis- 
kette image, if present, will be booted from the system 
partition. In addition ; if a system reference diskette is 
detected in diskette drive A, the system reference dis- 
kette will take precedence over the image in the system 35 
partition and will be booted instead. In these situations, 
BIOS will ensure that the protection means are inactive 
prior to the Bootstrap Loader turning control over the 
boot record. Thus, the protection means to prevent ac- 
cess to the region on the disk containing the master boot 40 
record, the BIOS image and the system reference dis- 
kette image will not be active. BIOS then will boot up the 
system reference diskette image or the system refer- 
ence diskette with the region on the disk open to access 
by software. 45 

In the drawings: 



Fig. 4 is a flowchart describing the overall process 
for loading a BIOS image from a direct access stor- 
age device; 

Fig. 5 illustrates the record format for the master 
boot record; 

Fig. 6A is a flowchart describing the operation of the 
IBL routine; 

Fig. 6B is a flowchart showing the steps for loading 
a BIOS image from a fixed disk; 

Fig. 6C is a flowchart showing the steps for loading 
the BIOS image from a diskette; 

Fig. 6D is a flowchart showing greater detail in 
checking the compatibility between the master boot 
record and the planar/processor; 

Fig. 7 is a detailed flowchart showing the operation 
of the executable code segment of the master boot 
record; 

Fig. 8 is a block diagram for the controller of the di- 
rect access storage device; 

Fig. 9 is a flow diagram showing the operation of a 
disk controller to protect the IBL media stored on a 
disk drive; 

Fig. 1 0 is a flowchart showing a method for protect- 
ing the BIOS image; 

Fig. 11 is a flowchart describing the process for de- 
ciding when to load the system reference diskette 
image from a direct access storage device; 

Fig. 12 is a flow diagram showing the Bootstrap 
Loader booting the correct media including the sys- 
tem reference diskette image from a direct access 
storage device; and 

Fig. 1 3 is a flow diagram showing the modification 
to BIOS to enable the treatment of the system par- 
tition as the active partition on a fixed disk. 



Fig. 1 illustrates a cut away view of a personal com- Referring now to the drawings, and in particu lar to 

puter system embodying the invention and showing Fig. 1 , there is shown a cutaway version of a personal 
a system planar board connected to a plurality of so computer system 10, having a plurality of DASD (Direct 
direct access storage devices; Access Storage Devices) 12- 16 connected to a system 

or planar board 24 through a plurality of I/O slots 18. A 
Fig. 2 shows a system block diagram for the per- power supply 22 provides electrical power to the system 
sonal computer system of Fig. 1; 10 in a manner well known. The planar board 24 in- 

55 eludes a system processor which operates under the 
Fig. 3 is a memory map for the ROM BIOS included control of computer instructions to input, process, and 

on the planar board; output information. 

In use, the personal computer system 10 is de- 
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signed primarily to give independent computing power 
to a small group of users or a single user and is inex- 
pensively priced for purchase by individuals or small 
businesses. In operation, the system processor oper- 
ates under an operating system, such as IBM's OS/2 
Operating System or DOS. This type of operating sys- 
tem includes a BIOS interface between the DASD 12 - 
16 and the Operating System. A portion of BIOS divided 
into modules by function is stored in ROM on the planar 
24 and hereinafter will be referred to as ROM-BIOS. BI- 
OS provides an interface between the hardware and the 
operating system software to enable a programmer or 
user to program their machines without an indepth op- 
erating knowledge of a particular device. For example, 
a BIOS diskette module permits a programmer to pro- 
gram the diskette drive without an indepth knowledge of 
the diskette drive hardware. Thus, a number of diskette 
drives designed and manufactured by different compa- 
nies can be used in the system. This not only lowers the 
cost of the system 1 0, but permits a user to choose from 
a number of diskette drives. 

Prior to relating the above structure to the present 
invention, a summary of the operation in general of the 
personal computer system 10 may merit review. Refer- 
ring to Fig. 2, there is shown a block diagram of the per- 
sonal computer system 10. Fig. 2 illustrates compo- 
nents of the planar 24 and the connection of the planar 
24 to the I/O slots 1 8 and other hardware of the personal 
computer system. Located on the planar 24 is the sys- 
tem processor 26 comprised of a microprocessor which 
is connected by a local bus 28 to a memory controller 
30 wh ich is further connected to a random access mem- 
ory (RAM) 32. While any appropriate microprocessor 
can be used, one suitable microprocessor is the 80386 
which is sold by Intel. 

The system processor could be an Intel 80286 or 
80486 microprocessor. 

Accessible by the processor is a planar identifica- 
tion number (planar ID). The planar ID is unique to the 
planar and identifies the type of planar being used. For 
example, the planar ID can be hardwired to be read 
through an I/O port of the system processor 26 or by 
using switches. Additionally, another I/O port of the sys- 
tem processor 26 can be used to generate a reset signal 
using planar logic circuitry to the disk controller. For in- 
stance, the reset signal can be initiated by software ad- 
dressing the I/O port and activating planar logic to gen- 
erate the reset signal. 

The local bus 28 is further connected through a bus 
controller 34 to a read only memory (ROM) 36 on the 
planar 24. An additional nonvolatile memory (NVRAM) 
58 is connected to the microprocessor 26 through a se- 
rial/parallel port interface 40 which is further connected 
to bus controller 34. The nonvolatile memory can be 
CMOS with battery backup to retain information when- 
ever power is removed from the system. Since the ROM 
is normally resident on the planar, model and submodel 
values stored in ROM are used to identify the system 



processor and the system planar I/O configuration re- 
spectively. This these values will physically identify the 
processor and planar I/O configuration. 

The NVRAM is used to store system configuration 
5 data. That is, the NVRAM will contain values which de- 
scribe the present configuration of the system. For ex- 
ample, NVRAM contains information describing the ca- 
pacity of a fixed disk or diskette, the type of display, the 
amount of memory, time, date, etc. Additionally the 
70 model and submodel values stored in ROM are copied 
to NVRAM whenever a special configuration program, 
such as SET Configuration, is executed. The purpose 
of the SET Configuration program is to store values 
characterising the configuration of the system in 
15 NVRAM. Thus for a system that is configured properly, 
the model and submodel values in NVRAM will be equal 
respectively to the model and submodel values stored 
in ROM. If these values are not equal, this indicates that 
the configuration of the system has been modified. Ref- 
20 erence is made to Fig. 6D, where this feature in combi- 
nation with loading BIOS is explained in greater detail. 

Continuing, our discussion with reference to Fig. 2, 
the bus controller 34 is further coupled to I/O slots 18, 
the serial/parallel interface 40 and peripheral controller 
25 42 by an I/O planar bus 43. The peripheral controller 42 
is further connected to a keyboard 44, mouse 46, diag- 
nostic panel 47, and diskette controller 64. Beside the 
NVRAM 58, the serial/parallel interface 40 is further con- 
nected to a serial port 48 and parallel port 50 to input/ 
30 output information to a printer, hard copy device, etc. As 
is well known in the art, the local bus 28 can also be 
connected to a cache controller 52, a cache memory 68, 
a co-processor 54, and a DMA controller 56. 

The system processor 26 controls its internal oper- 
as ation as well as interfacing with other elements of the 
personal computer system 10. For example, system 
processor 26 is shown connected to a small computer 
system interface (SCSI) I/O card 60 which is further con- 
nected to a DASD, such as a fixed disk drive 62. It is to 
40 be understood that other than a SCSI disk drive can be 
used as a fixed disk in accordance with the present in- 
vention. In addition to the fixed disk 62, the system proc- 
essor 26 can be interfaced to the diskette controller 64 
which controls a diskette drive 66. With respect to ter- 
45 minology, it is also to be understood that the term "hard- 
file" describes fixed disk drive 62 while the term "floppy" 
also describes diskette drive 66. 

Previous to the present invention, ROM 36 would 
include all of the BIOS code which interfaced the oper- 
so ating system to the hardware peripherals. According to 
one aspect of the present invention, however, ROM 36 
is adapted to store only a portion of BIOS. This portion, 
when executed by the system processor 26, inputs from 
either the fixed disk 62 or diskette 66 a second or re- 
55 maining portion of BIOS, hereinafter also referred to as 
a BIOS image. This BIOS image supersedes the first 
BIOS portion and being an integral part of the system is 
resident in main memory such as RAM 32. The first por- 
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tion of BIOS (ROM-BIOS) as stored in ROM 36 will be 
explained generally with respect to Figs. 3-4 and in de- 
tail with respect to Figs. 6A-D. The second portion of 
BIOS (BIOS image) will be explained with respect to Fig. 
5, and the loading of the BIOS image with respect to Fig. 
7. Another benefit from loading a BIOS image from a 
DASD is the ability to load BIOS directly into the system 
processor's RAM 32. Since accessing RAM is much 
faster than accessing ROM, a significant improvement 
in the processing speed of the computer system is 
achieved. An additional advantage is also gained by 
storing system utilities on the DASD. When a condition 
for the usage of the system utilities is required, the sys- 
tem utility can automatically be referenced on the 
DASD. 

The explanation will now proceed to the operation 
of the BIOS in ROM 36 and to the operation of loading 
the BIOS image and system reference diskette image 
from either the fixed disk or diskette. In general, a first 
program such as ROM-BIOS prechecks the system and 
loads a BIOS master boot record into RAM. The master 
boot record includes a data segment having validation 
information and, being a loading means, a code seg- 
ment having executable code. The executable code us- 
es the data information to validate hardware compatibil- 
ity and system configuration. After testing for hardware 
compatibility and proper system configuration, the exe- 
cutable code loads the BIOS image into RAM producing 
a main memory resident program. The BIOS image suc- 
ceeds ROM-BIOS and loads the operating system to be- 
gin operation of the machine. For purposes of clarity, the 
executable code segment of the master boot record will 
be referred to as MBR code while the data segment will 
be referred to as MBR data. 

Referring to Fig. 3 there is a memory map showing 
the different code modules which comprise ROM-BIOS. 
ROM-BIOS includes a power on self test (POST) stage 
I module 70, an Initial BIOS Load (IBL) Routine module 
72, a Diskette module 74, a hardfile module 76, a video 
module 78, a diagnostic-panel module 80, and hard- 
ware compatibility data 82. Briefly, POST Stage 1 70 per- 
forms system pre-initialisation and tests. Th e I BL routine 
72 determines whether the BIOS image is to be loaded 
from disk or diskette, checks compatibility and loads the 
master boot record. Diskette module 74 provides input/ 
output functions for a diskette drive. Hardfile module 76 
controls I/O to a fixed disk or the like. Video module 78 
controls output functions to a video I/O controller which 
is further connected to a video display. Diagnostic panel 
module 80 provides control to a diagnostic display de- 
vice for the system. The hardware compatibility data 82 
includes such values as a system model and submodel 
values which are described later with respect to Fig. 5. 

Referring now to Fig. 4, there is shown a process 
overview for loading a BIOS image into the system from 
either the fixed disk or the diskette. When the system is 
powered up, the system processor is vectored to the en- 
try point of POST Stage I, step 100. POST Stage I ini- 



tialises the system and tests only those system func- 
tions needed to load BIOS image from the selected 
DASD, step 102. In particular, POST Stage I initialises 
the processor/planar functions, diagnostic panel, mem- 
5 ory subsystem, interrupt controllers, timers, DMA sub- 
system, fixed disk BIOS routine (Hardfile module 76), 
and diskette BIOS routine (Diskette module 74), if nec- 
essary. 

After POST Stage I pre-initialises the system, 

70 POST Stage I vectors the system processor to the Initial 
BIOS Load (IBL) routine included in the Initial BIOS 
Load module 72. The IBL routine first, determines 
whether the BIOS image is stored on fixed disk or can 
be loaded from diskette; and second, loads the master 

15 boot record from the selected media (either disk or dis- 
kette) into RAM, step 104. The master boot record in- 
cludes the MBR data and the MBR code. The MBR data 
is used for verification purposes and the MBR code is 
executed to load in the BIOS image. A detailed descrip- 

20 tion of the operation of the IBL routine is presented with 
respect to Figs. 6A-D. 

With continuing reference to Fig. 4, after the IBL 
routine loads the master boot record into RAM, the sys- 
tem processor is vectored to the starting address of the 

25 MBR code to begin execution, step 1 06. The MBR code 
performs a series of validity tests to determine the au- 
thenticity of the BIOS image and to verify the configura- 
tion of the system. For a better understanding of the op- 
eration of the MBR code, attention is directed to Fig. 7 

30 of the drawings wherein the MBR code is described in 
greater detail. On the basis of these validity tests, the 
MBR code loads the BIOS image into RAM and trans- 
fers control to the newly loaded BIOS image in main 
memory, step 108. In particular, the BIOS image is load- 

35 ed into the address space previously occupied by ROM- 
BIOS. That is if ROM-BIOS is addressed from E0000H 
through FFFFFH, then the BIOS image is loaded into 
this RAM address space this superseding ROM-BIOS. 
Control is then transferred to POST Stage II which is 

40 included in the newly loaded BIOS image thus abandon- 
ing ROM-BIOS. POST Stage II, now in RAM, initialises 
and tests the remaining system in order to load the op- 
erating system boot, steps 110-114. Before Stage II 
POST transfers control to the operating system, Stage 

45 || POST sets a protection means for preventing access 
to the disk partition holding the BIOS image. However, 
if an error is detected, Stage II POST can disable the 
protection means and invoke the system utilities in the 
system reference diskette image on the disk. Reference 

50 is made to Figs. 8-10 for a detailed discussion of this 
protection process. It is noted that during a warm start, 
the processor is vectored to step 108, bypassing steps 
100-106. 

For clarity, it is appropriate at this point to illustrate 
55 a representation for the format of the master boot 
record. Referring to Fig. 5, there is shown the master 
boot record. The boot record includes the executable 
code segment 120 and data segments 122-138. The 
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MBR code 120 includes DASD dependent code respon- 
sible for verifying the identity of the ROM-BIOS, check- 
ing that the IBL boot record is compatible with the sys- 
tem, verifying the system configuration, and loading the 
BIOS image from the selected DASD (disk or diskette). 
The data segments 122-138 include information used 
to define the media, identify and verify the master boot 
record, locate the BIOS image, and load the BIOS im- 
age. 

The master boot record is identified by a boot record 
signature 122. The boot record signature 122 can be a 
unique bit pattern, such as a character string "ABC", in 
the first three bytes of the record. The integrity of the 
master boot record is tested by a checksum value 132 
which is compared to a computed checksum value when 
the boot record is loaded. The data segments further 
include at least one compatible planar ID value 134, 
compatible model and submodel values 1 36. The mas- 
ter boot record's planar ID value defines which planar 
that the master boot record is valid for. Similarly, the 
master boot record's model and submodel values define 
the processor and planar I/O configuration respectively 
that the master boot record is valid for. It is noted that 
the boot record's signature and checksum identify a val- 
id master boot record, while the boot record's planar ID, 
boot record's model and boot record's submodel com- 
parisons are used to identify a boot record compatible 
with the system and to determine if the system configu- 
ration is valid. Another value, boot record pattern 124 is 
used to determine the validity of the ROM-BIOS. The 
boot record pattern 1 24 is compared to a corresponding 
pattern value stored in ROM. If the values match this 
indicates that a valid ROM-BIOS has initiated the load 
of a BIOS image from the selected media. 

The following description further describes in great- 
er detail each of the values in the master boot record 
and their functions: MBR Identifier (1 22): The first three 
bytes of the IBL boot record can consist of characters, 
such as "ABC". This signature is used to identify a boot 
record. 

MBR Code Segment (120): This code verifies the 
compatibility of the boot record with the planar and proc- 
essor by comparing corresponding planar id and model/ 
submodel values. If these values match, it will load the 
BIOS image from the chosen media to system RAM. If 
the system image (BIOS image loaded into memory) 
checksum is valid and no media load errors occur, the 
MBR code will transfer control to the POST Stage II rou- 
tine of the system image. 

MBR Pattern (124): The first field of the IBL boot 
record data segment contains a pattern, such as a char- 
acter string "ROM-BIOS 1 990". This string is used to val- 
idate the ROM-BIOS by comparing the Boot Pattern val- 
ue to the corresponding value stored in ROM (ROM-Pat- 
tern). 

MBR Version Date (126): The master boot record 
includes a version date for use by an update utility. 
System Partition Pointer (128): The data segment 



contains a media pointer to the beginning of the media 
system partition area for use by Stage II POST On an 
IBL diskette, the pointer is in track-head-sector format; 
on disk the pointer is in Relative Block Address (RBA) 
5 format. 

System Partition Type (130): The system partition 
type indicates the structure of the media system parti- 
tion. There are three types of system partition structures 
- full, minimal and not present. The full system partition 

70 contains the setup utility and diagnostics in addition to 
the BIOS image and master boot record. The minimal 
system partition contains just the BIOS image and mas- 
ter boot record. It may occur where a system does not 
have access to a hardfile having an IBL image, in this 

15 circumstance the system partition type indicates not 
present. In this instance, IBL will occurfrom the diskette. 
These three system partition types allow flexibility in 
how much space the system partition takes up on the 
media. 

20 Checksum value (1 32): The checksum value of the 
data segment is initialised to generate a valid checksum 
for the record length value (1.5k bytes) of the master 
boot record code. 

MBR Planar ID Value (134): The data segment in- 
25 eludes a value, such as a string of words defining com- 
patible planar IDs. Each word is made up of a 16 bit pla- 
nar I D and the string is terminated by word value of zero. 
If a system's planar ID matches the planar ID value in 
the master boot record, such as one of the words in the 
30 string, the IBL media image is compatible with the sys- 
tem planar. If the system's planar I D does not match any 
word in the string, the I BL media image is not compatible 
with the system planar. 

MBR model and submodel values (136): The data 
35 segment includes values, such as a string of words de- 
fining compatible processors. Each word is made up of 
a model and submodel value andthe string isterminated 
by a word value of zero. If a system's model and sub- 
model value (stored in ROM) match one of the words in 
40 the string, the IBL media image is compatible with the 
system processor. If the ROM model and ROM submod- 
el values do not match any word in the string, the IBL 
media image is not compatible with the system proces- 
sor. 

45 MBR Map length (138): The IBL map length is ini- 
tialised to the number of media image blocks. In other 
words, if the BIOS image is broken into four blocks, the 
map length will be four indicating four block pointer/ 
length fields. Usually this length is set to one, since the 
50 media image is one contiguous 1 28k block. MBR Media 
Sector Size (138): This word value is initialised to the 
media sector size in bytes per sector. 

Media image block pointer (1 38): The media image 
block pointer locates a system image block on the me- 
55 dia. Normally, there is only one pointer since the media 
image is stored as one contiguous block. On an IBL dis- 
kette, the pointers are in track-head-sector format; on 
disk the pointers are relative block address format. 
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Media image block length (138): The media image 
block length indicates the size (in sectors) of the block 
located at the corresponding image block pointer. In the 
case of a 1 28k contiguous media image, which includes 
space for BASIC : this field is set to 256, indicating that 
the BIOS image block takes up 256 sectors (512 bytes/ 
sector) starting at the media image block pointer loca- 
tion. 

Referring now to Figs. 6A-D, there is shown a de- 
tailed flow chart of the operation of the IBL routine. Un- 
der normal circumstances, the IBL routine loads the 
master boot record from the system fixed disk into RAM 
at a specific address and then vectors the system proc- 
essor to begin executing the code segment of the mas- 
ter boot record. The I BL routine also contains provisions 
for a diskette default mode in which the master boot 
record can be loaded from diskette. However the IBL 
routine does not allow the diskette default mode to be 
performed if the system contains the IBL media on the 
system fixed disk and a valid password is present in 
NVRAM. The user has the option of setting the pass- 
word in NVRAM. The purpose of preventing the diskette 
default mode from being effected is to prevent loading 
an unauthorised BIOS image from diskette. In other 
words, the diskette default mode is used only when a 
system fixed disk is not operational and the user has 
indicated (by not setting the password) the desire to be 
able to load from the diskette. If the IBL routine is not 
able to load the master boot record from either media, 
an error message is generated and the system is halted. 

Referring now to Fig. 6A, under normal circum- 
stances the system will contain a system fixed disk 
which the IBL routine initialised, step 150. Assume for 
purposes of illustration that the fixed disk is configured 
for Drive C of the personal computer system. Similarly, 
assume Drive A is designated as the diskette drive. The 
I BL routine then examines Drive C to determine whether 
it contains IBL media, step 152. Attention is directed to 
Fig. 6B which describes in detail this process. The IBL 
routine starts reading from the fixed disk at the last three 
sectors and continues reading, decrementing the media 
pointer, for 99 sectors or until a valid master boot record 
is found. If a master boot record is found, it is checked 
for system planar and processor compatibility step 156. 
If it is not planar or processor compatible ; then an error 
is reported, step 158. Referring back to step 152, if no 
master boot record is found on the last 99 sectors of the 
fixed disk (primary hardfile), an error is reported, step 
154. 

Referring back to step 1 56, if a master boot record 
is found, a series of validity checks are performed to de- 
termine if the master boot record is compatible with the 
computer system. Additionally the configuration of the 
system is checked. Attention is directed to Fig. 6D which 
discloses this process in greater detail. If the boot record 
is compatible with the planar ID, model and submodel, 
and if furthermore the system configuration has not 
changed the master boot record is loaded and the code 



segment of the master boot record is executed, step 
160. 

Referring back to steps 1 54 and 1 58, if an error oc- 
curs in loading the master boot record from the fixed disk 

5 or if a fixed disk is not available, the IBL routine deter- 
mines if a valid password is included in NVRAM, step 
162. This password determines whether the BIOS im- 
age can be loaded from diskette. Note that the password 
will exist only upon being installed by the user running 

70 a set features utility. If a password is installed in NVRAM, 
the BIOS image is prevented from being loaded from 
diskette, step 164. This permits the user to ensure the 
integrity of the operation of the system by causing the 
system to be loaded only with the BIOS image on the 

15 fixed disk. The password can take the form of a string 
of characters stored in NVRAM. 

Referring back to step 162, if a valid password in 
NVRAM is not present, thus allowing BIOS image to be 
loaded from diskette, the IBL routine initialised the dis- 

20 kette subsystem, step 166. The IBL routine then deter- 
mines if Drive A includes the IBL media on a diskette, 
step 168. If Drive A does not include IBL media, an error 
is generated to notify the user that an invalid diskette 
has been inserted in the drive, step 170. The system 

25 then halts, step 172. Attention is directed to Fig. 6C for 
a more detailed discussion of step 168. 

Referring back to step 1 68, after Drive A is checked 
for IBL media, the master boot record is loaded into RAM 
and the code segment included in the master boot 

30 record is executed, step 1 60. It is important to note that 
for diskette the IBL routine does not include the validity 
checks that are used with the fixed disk system. The rea- 
son for the absence of the validity checks is for loading 
a non-compatible IBL image from diskette. For example, 

35 if a new processor is added to the system, a new BIOS 
image will be included on a diskette. Since a new proc- 
essor will cause validity errors when loading from fixed 
disk, the IBL routine provides the ability to bypass these 
tests by loading the BIOS image from diskette. 

40 To recapitulate, the master boot record is checked 
for compatibility with the system through matching the 
system planar ID and processor model/submodel val- 
ues to the boot record values. For disk, this check is 
done first in the IBL routine 72 and then done again in 

45 the IBL boot record. The first check (in the IBL routine) 
is done to make sure the boot record is compatible with 
the system; the second check (in the boot record) is 
done to ensure a compatible ROM passed control to the 
boot record. Notice that the check done in the disk boot 

50 record will never fail for a compatible ROM since the IBL 
routine will have already checked the compatibility. In 
contrast, the first compatibility check is not done for dis- 
kette. The planar/processor compatibility is checked on- 
ly during diskette boot record execution. This method 

55 allows future modifications in loading a new BIOS image 
from a reference diskette. 

In view of the description of the IBL routine of Fig. 
6A : the explanation will now proceed to a comprehen- 
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sive and full understanding of the validity tests dis- 
cussed above. Referring to Fig. 6B, there is shown a 
detailed flowchart of step 152 of Fig. 6A, to determine if 
a valid master boot record is on drive C. The process 
begins by obtaining the drive parameters to enable the 
IBL routine to access drive C, step 200. An IBL load lo- 
cation is set to the last three sectors from the disk (the 
last three sectors normally contain the master boot 
record), step 202. A load count indicating the number of 
attempts to read a master boot record from disk is set 
to 1 , step 204. Three sectors are read from disk at the 
IBL load location, step 206. Any disk drive errors are 
detected and if a disk drive read error occurs it is report- 
ed, steps 208-210. The process then returns with an er- 
ror indication, steps 212-214. 

Referring back to step 208, if no drive error occurs, 
the disk record is scanned for the master boot record 
signature, step 216. The boot record signature, such as 
the characters "ABC", are compared to the first three 
bytes of the disk record. If the disk record does have a 
valid boot record signature (characters "ABC") and the 
checksum computed from the disk record loaded into 
memory equals the boot record checksum, the disk 
record is indicated as being a valid boot record with no 
errors, step 218. The process then returns, step 214. 

Referring back to step 216, if the boot record signa- 
ture or checksum is invalid, the load count is increment- 
ed by 1 , step 220. The load count is then compared to 
a predetermined constant such as 99, step 222. If 99 
attempts to read a boot record have resulted in failure, 
an error is indicated and the process returns, steps 224, 
212 and 214. If less than 99 attempts to read a boot 
record have occurred, the IBL load location is decre- 
mented by one and three new sectors are read from the 
new load location, steps 226 and 206. Thus if a valid IBL 
boot record cannot be loaded from the last 99 sectors 
(equivalent to 33 copies) then an error condition is set 
and control returns to the IBL routine. 

Referring now to Fig. 6C, there is shown a detailed 
flow diagram for loading the master boot record from dis- 
kette on drive A. First, the diskette drive parameters to 
access drive A are retrieved, step 230. The IBL load lo- 
cation is set to the last 3 sectors on diskette (cylinder, 
head and sector format), step 232. The last 3 sectors 
are read, step 234. If a diskette drive error is detected 
an error is indicated, steps 236-238. An error condition 
is set and control is returned to the IBL routine, steps 
240-242. 

Referring back to step 236, if no drive error is de- 
tected, the diskette record is checked for boot record 
signature and the checksum is calculated, step 244. If 
the boot record signature is missing or checksum is 
invalid, an error is indicated and control returned to the 
IBL routine, steps 244, 246, 240 and 242. If a valid boot 
record signature and valid checksum are detected an 
indication is set and control is returned to the IBL routine, 
steps 248 and 242. It is noted that in a diskette load, the 
IBL routine does not search through the media as in the 



fixed disk load. Therefore, in a diskette load, the I BL me- 
dia must be stored in a specific location of the diskette. 

Finally, Fig. 6D shows how the I BL routines tests for 
system planar and processor compatibility and for a 

5 proper system configuration. The master boot record is 
checked for compatibility with the system planar by com- 
paring the boot record planar ID value to the system pla- 
nar ID read by the system processor, step 260. If the 
system planar ID does not match the boot record planar 

70 id value, this indicates this master boot record is not 
compatible with this planar. An error is indicated and 
control returns to the IBL routine, steps 262, 264, and 
266. 

If the master boot record is compatible with the pla- 

15 nar, the master boot record is checked for compatibility 
with the processor, step 268. The boot record model val- 
ue and submodel value are compared to the model val- 
ue and submodel value stored in ROM respectively. A 
mismatch indicates a new processor has probably been 

20 inserted and this boot record is not compatible with the 
new processor. An error is indicated and control re- 
turned to the IBL routine, steps 270, 264 and 266. If the 
master boot record is compatible with the planar and 
processor, the process checks to determine if NVRAM 

25 is reliable, step 272. If NVRAM is unreliable, an error is 
indicated and control returned to the IBL routine, steps 
274 and 266. If NVRAM is reliable, the system configu- 
ration is checked, step 276. A change in system config- 
uration is indicated if the model and submodel values 

30 stored in NVRAM do not match the model and submodel 
values stored in ROM. Note that this last comparison 
will only indicate a configuration error. If a configuration 
error is indicated, an error is generated for the user. This 
error notifies the user that the configuration of the sys- 

35 tern has changed since the last time SET Configuration 
was run. The user is notified of the changed configura- 
tion and control passed back to the IBL routine steps 
278, 264, and 266. This error is not fatal itself, but noti- 
fies the user that SET Configuration (configuration pro- 

40 gram) must be executed. Referring back to step 276, if 
the system model/submodel values match, an indication 
of comparability is set and the routine returns, steps 276, 
274 and 266. Thus, the compatibility between the mas- 
ter boot record and the system are tested along with de- 

45 termining if the system configuration has been modified. 
After the IBL routine loads the master boot record 
into RAM, it transfers control to the MBR code starting 
address. Referring to Fig. 7, the executable code seg- 
ment of the master boot record first verifies the boot 

50 record pattern to the ROM pattern, step 300. If the pat- 
tern in the master boot record does not match the pat- 
tern in ROM, an error is generated and the system halts, 
steps 302 and 305. The check for equality between 
ROM and boot record patterns ensures that the master 

55 boot record loaded from either the disk or diskette is 
compatible with the ROM on the planar board. Referring 
back to step 300, if the pattern in ROM matches the pat- 
tern in the boot record, the MBR code compares the sys- 
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tem planar ID value, model and submodel value against 
the corresponding master boot record values, step 304. 
This process was discussed in greater detail with re- 
spect to Fig. 6D. If the values don't match, the master 
boot record is not compatible with the system planar and 
processor, or the system configuration has changed, 
and an error is generated, step 306. The system will halt 
when the IBL record is incompatible with planar, model 
or submodel values, step 305. 

Referring back to step 304, if the system planar ID 
value, model and submodel values match the corre- 
sponding master boot record values, the MBR code 
loads the BIOS image from the selected media into the 
system RAM, step 308. If a media load error occurs in 
reading the data : step 310, an error is generated and 
the system halts, steps 312 and 305. Referring back to 
step 310, if no media load error occurs, a checksum is 
calculated for the BIOS image in memory, step 314. If 
the checksum is invalid an error is generated and the 
system halts, steps 31 8 and 305. Referring back to step 
31 6, if the checksum is valid, the system partition point- 
ers are saved, step 320, and the system processor is 
vectored to POST Stage II to begin loading the system, 
step 322. 

Referring to Fig. 8, there is shown a block diagram 
of an intelligent disk controller 350 for controlling move- 
ment of data between the disk drive 351 and the system 
processor. It is understood that disk controller 350 can 
be incorporated into the adapter card 60 while disk drive 

351 can be included onto drive 62 of Fig. 2. A suitable 
disk controller 350 is a SCSI Adapter having a part 
number of 33F8740, which is manufactured by Interna- 
tional Business Machines Corporation. It is understood 
that the disk controller 350 includes a microprocessor 

352 operating under its own internal clock, for controlling 
its internal operations as well as its interfacing with the 
other elements of the disk subsystem and the system 
processor. The microprocessor 352 is coupled by a in- 
struction bus 354 to a read only memory (ROM) 356 
which stores instructions which the disk controller 350 
executes to process and control the movement of data 
between the disk drive and the system processor. It is 
also understood that disk controller 350 can include ran- 
dom access memory coupled to microprocessor 352 for 
the storage or retrieval of data. The movement of data 
between disk controller 350 and the system processor 
is effected by data bus 358 and instruction bus 360. A 
reset signal on line 362 resets or initialises the disk con- 
troller logic upon power-on sequence or during a system 
reset. The reset signal is generated by the planar board 
logic, and can take the form of a channel reset signal as 
provided by IBM's Micro Channel architecture as de- 
scribed in "IBM PERSONAL SYSTEM/2 Seminar Pro- 
ceedings", Volume 5, Number 3, May 1 987 as published 
by the International Business Machines Corporation En- 
try Systems Division. Furthermore, the reset signal can 
be effectively initiated by BIOS outputting a particular bit 
configuration to an I/O port of the system processor in 



which the planar logic is connected. 

As is well known, the microprocessor 352 provides 
all the interfacing and timing signals to effect the efficient 
transfer of data between the disk drive and the system 

5 processor. For clarity, only those signals important for 
the understanding of the invention are presented. It is 
understood that other signals and lines, such as data 
bus 364, are used but are not presented here since they 
are not important for the understanding of the present 

70 invention. It is further understood that only those pro- 
grams or routines as stored in ROM 356 important for 
the understanding of the present invention are ex- 
plained with respect to Fig. 9. 

Referring now to Fig. 9, there is shown a flowchart 

15 diagramming the read, write, and protect functions of the 
disk controller which are effected by the operation of 
routines stored in ROM 356. In operation, a disk instruc- 
tion is initiated by the system processor and transferred 
to the disk controller 350. The disk controller receives 

20 and interprets the instruction to perform the designated 
operation, step 400. The disk controller first determines 
if this is a write operation in which data from the system 
processor are stored on the disk drive hardware, step 
402. If the instruction is a write instruction, data are re- 

25 ceived from the system processor in relative block ad- 
dress (RBA) format. 

Prior to continuing the discussion above, a brief ex- 
planation of the relative block address format applied to 
a mass storage device, such as a disk, may merit review. 

30 RBA is a scheme in which data in mass storage are ad- 
dressed in predetermined sized blocks by sequential 
numbers, i.e. individual definable contiguous blocks of 
data. For example, assuming a block size of 1 024 bytes, 
the system processor can approximately address 

35 10,000 blocks for a 10 megabyte disk. That is, the sys- 
tem processor can address the disk media in terms of 
N blocks where N ranges from 0 to 9,999. It has been 
discovered, that the use of RBA provides a very fast and 
efficient method for addressing mass storage in the type 

40 of operating systems used for personal computer sys- 
tems of the present invention. 

For convenience sake, the following assumptions 
will be introduced: first, the disk can support a total of N 
blocks; second, the system processor transfers a K 

45 block, where K is greater than or equal to 0 and is less 
than or equal to (N-1); third, the disk controller can set 
a maximum addressable block M which permits access 
to data blocks where K is less than M and denies access 
to data blocks where K is greater than or equal to M. 

50 Note, by setting M less than N a protectable region on 
the disk is generated from M to N-1 blocks. This feature 
permits the IBL media to be protected as will be dis- 
cussed below. 

Continuing our discussion with reference to Fig. 9, 

55 the data are received from the disk in RBA format, step 
404. The disk controller then determines if the received 
block K is less than the maximum block value M, where 
M is less than M, step 406. If K is less than M then the 
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disk controller converts the RBA format into the partic- 
ular format for the mass storage device, such as cylin- 
der-head-sector (CHS) format for a fixed disk, step 408. 
For instance ; the disk controller by using a look up table 
could convert RBA addresses to unique cylinder-head- 
sector location. Another method is the use of a conver- 
sion formula to convert RBA to CHS. For example, for 
a disk having one head ; 64 cylinders, and 96 sectors: 
Head = 0, cylinders = quotient of RBA/(96), and sectors 
= remainder of RBA/(96). After converting the RBA for- 
mat to a CHS format the data are written to disk at the 
converted CHS location, step 410. The disk controller 
then waits for another instruction from the system proc- 
essor, step 412. 

Referring back to step 406, if the received RBA is 
greater than the maximum set RBA value, access is de- 
nied, step 414. That is if K is greater than or equal to M, 
the K block is not written to the disk. Please note, if the 
I BL media is stored in the blocks from M to N-1 , then the 
IBL media will be protected from writing. 

Referring back to step 402, if the instruction from 
the system processor is not a write instruction, it is test- 
ed for being a read instruction, step 41 6. If the instruction 
is a read instruction, the system processor sends the 
RBA format for the data requested, step 418. The disk 
controller then determines if the desired RBA (K) is less 
than the maximum set RBA (M). If the desired RBA (K) 
is less than the maximum set RBA (M), then the disk 
controller converts the RBA to the appropriate CHS for- 
mat and reads the data from the disk, steps 422 and 
424. The data are then transferred to the system proc- 
essor, step 412. 

Referring back to step 420, if the received RBA (K) 
is greater than or equal to the maximum set RBA (M), 
access is denied, step 426. If the IBL media is stored 
between M blocks and (N-1 ) blocks, access is denied to 
this area. Please note, that in this circumstance, the IBL 
media is also protected from copying. 

Referring back to step 416, if the instruction is not 
a write or read instruction, it is tested for a set maximum 
RBA instruction, step 428. This instruction allows the 
disk controller to create a protectable area or partition 
on the disk drive hardware. This instruction allows the 
disk controller to set M between 0 and N blocks, step 
430. It is important to note that when the disk controller 
is reset (through the reset signal) that M is set so that 
the maximum number of blocks are available. That is, 
when the disk controller is reset, M=N. Essentially pro- 
tection for the protectable area is eliminated upon reset- 
ting the disk controller, allowing access to the area. 
However, once the set maximum RBA instruction is ex- 
ecuted only a reset or another set maximum RBA in- 
struction will allow access to the protectable area. Con- 
ceptually, the setting of the maximum RBA can be 
thought of as setting a fence which protects access to 
the area above the fence while allowing access to the 
area below the fence. The disk controller then returns 
to wait for another instruction, step 412. 



Referring back to step 428, if the instruction is not 
a read, write, or set maximum RBA instruction, it is test- 
ed for another disk controller instruction and executed, 
step 432. These instructions will use the set maximum 
5 RBA value but are not important for the understanding 
of the present invention and are not presented here for 
brevity purposes. Thediskcontrollerthen returns to wait 
for another instruction, step 412. 

The explanation will now proceed to the operation 
70 of the loading in and protecting the IBL media in view of 
the proceeding discussion. In general, from either a cold 
start (power-on) or a warm start (Ctrl-Alt-Del), the disk 
controller having the IBL media is reset. This causes the 
maximum RBA (M) to be set to N, i.e. the fence is re- 
75 moved allowing access to the IBL media. This is re- 
quired to allowthe system to load the I BL media to begin 
operation. Once the IBL media is loaded and executed 
the fence is erected (set maximum RBA below IBL me- 
dia) to prevent access to the IBL media stored on disk. 
20 Referring nowto Fig. 10, there is shown a block flow 
diagram effecting the protection of the IBL, media. From 
a power-on condition the system is initialised and BIOS 
in itiates activity in planar board logic to send a reset con - 
dition to the disk controller, steps 450 and 452. The reset 
25 signal drops the fence and allows the system processor 
to access the IBL media previously stored on the disk 
in the area from M blocks to N blocks. The system loads 
the I BL media as previously described with reference to 
Fig. 4-7, step 454. During the I BL loading sequence Post 
30 Stage 1 1 is executed, step 456. One of the tasks of POST 
Stage II is to execute the set maximum RBA instruction 
with the maximum RBA set to the first block of the IBL 
media which is designated as M, step 458. M is depend- 
ent upon partition type (none, partial or full) as previous- 
35 |y explained. This in effect sets the fence denying ac- 
cess to the IBL media while allowing access to other re- 
gions of the disk. The operating system is then booted 
up in a normal fashion, step 460. 

If the system is started from a warm start condition, 
40 such as Ctrl-Alt-Del, the planar logic is commanded to 
reset the disk controller by POST Stage II, steps 462 
and 464. This causes the fence to be dropped. In this 
circumstance, since the IBL media is already present in 
RAM, the IBL media is not loaded again. However, since 
45 the protection for the IBL media is eliminated POST 
Stage II must be executed to reset the fence, steps 456 
and 458. The fence is erected protecting the IBL media 
and the system is then rebooted in a normal manner, 
step 460. 

50 The IBL media is protected by addressing mass 
storage in blocks and setting a maximum block the sys- 
tem can access during normal operation. The IBL media 
is stored consecutively in those blocks between the 
maximum block accessible and the total number of 
55 blocks supported by the disk drive. A reset signal sent 
to the disk controller eliminates the maximum block ac- 
cessible to permit the system to address the IBL media. 
The reset signal is generated during a power-on condi- 
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tion or a warm -start condition to permit access to the IBL 
media to boot up the system. 

Referring now to Fig. 1 1 , the flowchart describes the 
process by which POST Stage II follows to load the sys- 
tem reference diskette image from the system partition 
on the fixed disk 62. Prior to booting an operating sys- 
tem, such as DOS or IBM's OS/2, POST will ascertain 
the type of system partition present on the IBL, media, 
step 500. POST will then query the fixed disk 62 for the 
value of the last block address, step 502. POST will then 
adjust the value obtained as the last block address to 
account for the size of the system partition, step 504. 
This is done by subtracting from the physical last block 
address of the fixed disk 62 the amount of blocks in the 
system partition. POST saves the adjusted value as the 
logical last block address, step 506. By doing so POST 
has provided BIOS a mechanism to boot from the sys- 
tem partition instead of the beginning of the fixed disk 
partition. Reference is made to Fig. 13 for a more de- 
tailed discussion of the above. 

Proceeding further, with respect to Fig. 11, POST 
Stage II examines the current contents of the POST 
Path Flag, step 508. The POST Path Flag is one mech- 
anism used by POST to keep track of the type of path 
through POST For example, an initial power on path 
versus a warm reboot path. A warm reboot is typically 
enabled by a Ctrl-Alt-Del keystroke sequence. If the cur- 
rent value of the POST Path Flag indicates override sys- 
tem partition boot procedures, POST Stage II sets the 
System Partition Boot Flagtofalse ; indicating not to boot 
the system partition, step 510. POST Stage II then pro- 
tects the system partition by instructing BIOS to activate 
the protection means on the boot fixed disk based on 
the value calculated in step 506, step 511. That is, the 
fence is set to address pointer calculated in step 506. 
Thus, the system partition is protected to prevent inad- 
vertent destruction. Afterwards, POST Stage II invokes 
the Bootstrap Loader, INT 19H, to initiate operating sys- 
tem boot ; step 512. 

Referring back to step 508, if the POST Path Flag 
does not i ndicate an ove r r ide of th e system part it ion hoot 
sequence, then the POST Path Flag is examined for a 
warm boot path, POST indicating a Ctrl-Alt-Del key se- 
quence was entered, step 520. If the Path Flag does not 
indicate a warm boot, POST Stage II determines if any 
errors were detected during a cold startup execution, 
step 522. If no errors were detected, POST Stage II sets 
a flag indicating not to boot the System Partition, step 
510. POST Stage II now protects the system partition 
by instructing BIOS to activate the protection means as 
shown in step 511, followed by invoking the Bootstrap 
Loader, step 512. 

Referring back to step 522, if POST Stage II detects 
any errors during its execution, it sets the System Boot 
Partition Flag to true, step 526. POST Stage II then pro- 
tects the system partition by instructing BIOS to activate 
the protection means as shown in step 511 . Afterwards, 
POST Stage II invokes the Bootstrap Loader 512 to in- 



itiate the operating system boot. 

Referring back to step 520, if Ctrl-Alt-Del key se- 
quence was entered, POST Stage II checks to see if the 
user has entered the keystroke sequence Ctrl-Alt-lns. 

5 The Ctrl-Alt-lns keystroke instruction invokes the boot- 
ing of the system reference diskette image 524. This se- 
quence permits a user to force a bootup procedure from 
the system partition. If not, POST Stage II sets the Sys- 
tem Partition Boot Flag to false and protects the system 

70 partition by instructing BIOS to activate the protection 
means as shown in step 511. Afterwards ; POST Stage 
II invokes the Bootstrap Loader INT 19H, to initiate op- 
erating system boot, step 512. 

Referring back to step 524, if POST Stage II detects 

15 the user entered keystroke sequence of Ctrl-Alt-lns, it 
sets the System Partition Boot Flag to true, indicating 
boot the system partition, step 526. POST Stage II then 
protects the system partition by instructing BIOS to ac- 
tivate the protection means as shown in step 511; fol- 

20 lowed by invoking the Bootstrap Loader, step 512. 

At this point, POST Stage II has established if either 
a normal boot sequence or a boot of the system refer- 
ence diskette image in the system partition is to occur. 
Also, POST has established the beginning of the system 

25 partition as though it is a logical bootable partition and 
has activated the protection means to prevent access 
to the system partition by a program not considered to 
be trusted. A logical bootable partition appears to POST 
as the first partition on the disk and is therefore bootable. 

30 POST Stage II now invokes the Bootstrap Loader. 

The Bootstrap Loader is used to select the appro- 
priate boot device and read in the boot record from the 
active partition. The priority of the boot drives are the 
first diskette drive followed by the first fixed disk, such 

35 as the boot fixed disk. However, the priority of the default 
boot device sequence can be changed by using a utility 
on the system reference diskette or system reference 
diskette image in the system partition. The Bootstrap 
Loader then turns control over to the executable code 

40 in the boot record. This in turn boots the desired oper- 
ating system or control program. 

Continuing the discussion with respect with Fig. 12, 
there is shown a flowchart describing the logic flow in- 
side the Bootstrap Loader, INT 1 9H. To begin, the Boot- 

45 strap Loader checks for the actual presence of the sys- 
tem reference diskette in the first diskette drive, step 
600. The presence of a system reference diskette in the 
first diskette drive overrides all other reference dis- 
kettes. In other words, invoking the system reference 

50 diskette overrides the system reference diskette image 
in the system partition or a direct request by the user to 
boot the operating system if POST errors are detected. 
Next, the System Partition Boot Flag is checked, step 
620. Since the system reference diskette is present the 

55 System Partition Boot Flag is false. 

Being that the System Partition Boot Flag is false, 
the Bootstrap Loader determines if a Reference Dis- 
kette Boot is required, step 630. Since a system refer- 
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ence diskette is present in the first diskette drive, the 
Bootstrap Loader first instructs BIOS to deactivate the 
protection means for the system partition, step 640. 
Then the Bootstrap Loader establishes the system par- 
tition as the origin of the boot fixed disk by using the s 
value calculated in step 506 as the logical starting block 
address, step 650. The system partition is now unpro- 
tected. The Bootstrap Loader then fetches the boot 
record from the system reference diskette and passes 
control to it, step 660. The boot record then boots up the 10 
system reference diskette. For example, a user may be 
adding a new feature I/O adapter to the system and 
wants to install its adapter description file in the system 
partition. 

Referring back to step 600, if no system reference is 
diskette is present in the first diskette drive, the Boot- 
strap Loader checks the System Partition Boot Flag, 
step 61 2. If the flag indicates an operating system boot, 
the Boot Strap Loader transfers control to the selectable 
boot routine, step 614. The selectable boot routine then 20 
decides the physical device to boot from and proceeds 
to step 620. 

The System Partition Boot Flag is then accessed to 
determine if it is set, step 620. If a system partition boot 
is not requested, the Bootstrap Loader determines if a 25 
system reference diskette boot is required, step 630. For 
instance, a system reference diskette may be in a boota- 
ble diskette drive other than the first physical diskette 
drive. If no system reference diskette is present, the 
Bootstrap Loader fetches the operating system boot 30 
record and passes control to it, step 660. The system 
partition remains protected and the BIOS will access an- 
other partition, namely the operating system partition on 
the boot fixed disk. 

Referring back to step 630, if a system reference 35 
diskette boot is required, the Bootstrap Loader instructs 
BIOS to deactivate the protection means for the system 
partition and to establish the system partition as the or- 
igin of the boot fixed disk by using the value calculated 
in step 506 as the logical starting block address, step 40 
650. The Bootstrap Loader fetches the boot record from 
the reference diskette (in this case, a system reference 
diskette is present) and boots up the system reference 
diskette, step 660. The system partition is unprotected 
and is now the active partition on the fixed disk. This is 45 
done to allow access by the reference diskette. As pre- 
viously explained, a user may be adding a new feature 
I/O adapter to the system and wants to install its adapter 
description file in the system partition. 

Referring back to step 620, if the System Partition so 
Boot Flag is true : the Bootstrap Loader instructs BIOS 
to deactivate the protection means for the system par- 
tition step 640 and establish the system partition as the 
origin of the boot fixed disk by using the value calculated 
in step 506 as the logical starting block address, step 55 
650. The Bootstrap Loader then fetches the boot record 
from the system reference diskette image in the system 
partition and boots up the system reference diskette im- 



age, step 660. The system partition is unprotected and 
is now the active partition on the boot fixed disk. 

Referring back to step 612, if the System Partition 
Boot Flag indicates a system partition boot, the Boot- 
strap Loader checks for a valid boot record on the sys- 
tem partition, step 61 6. This step includes validating that 
the system partition is a full system partition; the boot 
record signature is valid; and a system reference dis- 
kette signature is present. If valid, the Bootstrap Loader 
queries the System Partition Boot Flag, step 620. Since 
it is true, the Bootstrap Loader instructs BIOS to deac- 
tivate the protection means for the system partition and 
establish the system partition as the origin of the boot 
fixed disk by using the value calculated in step 506 as 
the logical starting block address, steps 640 and 650. 
The Bootstrap Loader fetches the boot record from the 
system partition and boots up the system reference dis- 
kette image, step 660. The system partition is unprotect- 
ed and is now the active partition on the boot fixed disk. 

Referring back to step 616, if a valid boot record is 
not present, the Bootstrap Loader prompts the user to 
insert a system reference diskette in a diskette drive and 
press the 'Y' key on the keyboard, step 617. The Boot- 
strap Loader then waits for the key to be entered, step 
618. Once entered, the Bootstrap Loader checks that a 
valid system reference diskette is present, step 619. If 
not, the Bootstrap Loader repeats the process starting 
at step 617. 

Referring back to step 619, if the Bootstrap Loader 
finds a valid system reference diskette, it instructs BIOS 
to deactivate the protection means for the system par- 
tition and establish the system partition as the origin of 
the boot fixed disk by using the value calculated in step 
506 as the logical starting block address steps 640 and 
650. The system partition is now unprotected, the Boot- 
strap Loader fetches the boot record from the system 
reference diskette and passes control to it, step 660. 
The boot record boots up the system reference diskette. 

Figure 1 3 shows the BIOS modification required to 
support booting of the system reference diskette image 
from the system partition of the boot fixed disk or to allow 
access to the image when a system reference diskette 
is booted. When BIOS receives a request to perform a 
data transfer operation it determines if this is the boot 
fixed disk as shown in step 700. The boot fixed disk is 
the first physical fixed disk on the fixed disk adapter. If 
the fixed disk is not the boot fixed disk, BIOS performs 
the requested operation, step 730. 

Referring back to step 700, if the fixed disk is the 
boot fixed disk, BIOS checks to see if the System Par- 
tition Boot Flag is true or a system reference diskette is 
being booted, step 710. If neither istrue, BIOS performs 
the requested operation, step 730. 

Referring back to step 710, if the System Partition 
Boot Flag is true or a system reference diskette is being 
booted, the fixed disk block address calculated in step 
506 is added to any block address, after converted from 
the user supplied cylinder, head and sector parameters 
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provided with the request for a fixed disk data transfer 
function, step 720. This makes the system partition ap- 
pear as the first block on the fixed disk. Thus the system 
partition appears to be the active partition on the boot 
fixed disk. Afterwards, BIOS performs the requested op- 
eration, step 730. 

Thus, there has been shown a method and appa- 
ratus for booting the system reference diskette image 
from the system partition from a mass storage device, 
such as a fixed disk drive. The system partition is pro- 
vided by protecting an area on the disk drive. The sys- 
tem partition is made bootable by storing the starting ad- 
dress of system partition on the disk drive and indicating 
to BIOS to use this as the fixed disk origin when a boot 
of the system reference diskette image is requested or 
required. By providing this capability, the system refer- 
ence diskette utilities are automatically available any 
time the configuration is changed, a system utility is de- 
sired or an error is encountered during the execution of 
POST. Thus enhancing the usability of the system. 

Claims 

1 . A personal computer system having a system proc- 
essor (26) for executing an operating system, a 
read only memory (36), a random access memory 
(32), and peripheral devices including at least one 
direct access storage device (62), (66), the system 
having an interface program to control the move- 
ment of data into and out of the processor, charac- 
terised in that the direct access storage device has 
a protection means for protecting a region of the di- 
rect access storage device in which a portion of the 
interface program is stored, the protection means 
allowing access to the protected region in response 
to a reset signal, the said portion of the interface 
program being operable, when loaded into the ran- 
dom access memory, to boot the operating system 
and to activate the protection means to prevent ac- 
cess to the protected region of the direct access 
storage device during operation of the operating 
system, the protected region of the direct access 
storage device further including system utility pro- 
grams which are executed upon detecting an error 
condition in the loading of the operating system. 

2. A system as claimed in claim 1 , wherein the direct 
access storage device comprises a fixed disk. 

3. A system as claimed in claim 1 or 2, wherein said 
system utility programs comprise a program for 
modifying the configuration of the system. 

4. A system according to claim 1, 2 or 3 wherein an 
initialising portion of the interface program is stored 
in the read only memory and is operable to initialise 
the system processor and initiate generation of a 



reset signal to the direct access storage device to 
permit access thereto. 

5 Patentanspruche 

1. Ein Personalrechnersystem mit einem Systempro- 
zessor (26) zum Abarbeiten eines Betriebssystems, 
einem Festwertspeicher (36), einem Speicher mit 

70 wahlfreiem Zugriff (32) und Peripheriegeraten ein- 
schlieBlich wenigstens einer Direktzugriffsspei- 
chervorrichtung (62, 66), wobei das System ein 
Schnittstellenprogramm zur Steuerung der Daten- 
bewegung in den bzw. aus dem Prozessor aufweist, 

15 dadurch gekennzeichnet, daG die D ire ktzug riffs - 
speichervorrichtung ein Schutzmittel aufweist zum 
Schutzen eines Bereichs der Direktzugriffsspei- 
chervorrichtung, in der ein Teil des Schnittstellen- 
programms gespeichert ist, das Schutzmittel den 

20 Zugriff auf den geschutzten Bereich als Reaktion 
auf ein Ruckstellsignal zulaGt dieser Teil des 
Schnittstellenprogramms betriebsfahig ist, wenn er 
in den Speicher mit wahlfreiem Zugriff geladen ist, 
urn das Betriebssystem zu urladen und das Schutz- 

25 mittel zu aktivieren, urn den Zugriff auf den Schutz- 
bereich der Direktzugriffsspeichervorrichtung wah- 
rend des Abarbeitens des Betriebssystems zu ver- 
hindern, wobei der Schutzbereich der Direktzu- 
griffsspeichervorrichtung ferner Systemdienstpro- 

30 gramme beinhaltet, die abgearbeitet werden, so- 
bald beim Laden des Betriebsystems ein Fehlerzu- 
stand erkannt wird. 

2. Ein System gemaB Anspruch 1 , in dem die Direkt- 
35 zugriffsspeichervorrichtung eine Festplatte enthalt. 

3. Ein System gemaG Anspruch 1 oder 2, in dem die 
Systemdienstprogramme ein Programm zur Modi- 
fizierung der Systemkonfigu ration aufweisen. 

40 

4. Ein System gemaB Anspruch 1, 2 oder 3, in dem 
ein Initialisierungsteil des Schnittstellenprogramms 
im Festwertspeicher abgespeichert ist und betrie- 
ben werden kann, um den Systemprozessor zu in- 

45 itialisieren und die Generierung eines Ruckstellsi- 
gnals fur die Direktzugriffsspeichervorrichtung an- 
laufen zu lassen, um den Zugriff darauf zuzulassen. 

50 Revendications 

1. Un systeme d'ordinateur personnel comportant un 
processeur systeme (26) concu pour fonctionner 
sous un systeme d'exploitation, une memoire a lec- 
55 ture seule (36), une memoire a acces aleatoire (32) 
et des dispositifs peripheriques comprenant au 
moins un dispositif de stockage a acces direct (62), 
(66), le systeme comportant un programme d'inter- 
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face destine a commander le flux de donnees en 
entree et en sortie du processeur, caracterise en ce 
que le dispositif de stockage a acces direct compor- 
te des moyens de protection concus pour proteger 
la zone du dispositif de stockage a acces direct s 
dans laquelle une partie du programme d'interface 
est stockee, les moyens de protection permettant 
I'acces a la zone protegee en reponse a un signal 
de remise a I'etat initial, ladite partie du programme 
d'interface etant susceptible de fonctionner, une 10 
fois chargee dans la memoire a acces aleatoire, 
pour lancer le systeme d'exploitation et pour activer 
les moyens de protection, afin d'empecher un acces 
a la zone protegee du dispositif de stockage a acces 
direct pendant le fonctionnement du systeme d'ex- is 
ploitation, la zone protegee du dispositif de stocka- 
ge a acces direct comprenant en outre des pro- 
grammes utilitaires systeme, executes lorsde la de- 
tection d'un etat d'erreur dans le chargement du 
systeme d'exploitation. 20 

2. Un systeme selon la revendication 1 , dans lequel le 
dispositif de stockage a acces direct comprend un 
disque dur. 



Un systeme selon la revendication 1 ou 2, dans le- 
quel lesdits programmes utilitaires systeme com- 
prennent un programme congu pour modifier la con- 
figuration du systeme. 



25 



30 



Un systeme selon la revendication 1, 2 ou 3, dans 
lequel une partie d'initialisation du programme d'in- 
terface est memorisee dans la memoire a lecture 
seule et est susceptible de fonctionner, pour initia- 
liser le processeur systeme et initier la generation 35 
d'un signal de remise a I'etat initial au dispositif de 
stockage a acces direct, afin de permettre un acces 
a celui-ci. 
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